…#9342) (#10)

## What this does

Backports rocJPEG GPU JPEG decoding (upstream **pytorch#9342**)
to `release/0.26`, so `decode_jpeg(..., device="cuda")` works on ROCm
(MI300 / gfx94X) using rocJPEG's hardware backend for `UNCHANGED`,
`GRAY`, and `RGB` modes. Gated by `TORCHVISION_USE_ROCJPEG` /
`ROCJPEG_FOUND`, alongside the existing nvJPEG CUDA path.

## Why this is a manual backport (not a cherry-pick)

`pytorch#9342` was merged against `main`, which has since diverged
significantly from `release/0.26`. A `git cherry-pick` does not apply.
The change had to be re-implemented against the `release/0.26` layout:

- **Stable ABI vs classic API:** upstream uses the torch stable ABI
(`torch::stable::Tensor`, `STABLE_TORCH_LIBRARY_IMPL`,
`common_stable.*`, the separate `image_stable` extension).
`release/0.26` has none of that, so the decoder was rewritten with the
classic `torch::Tensor` / `at::empty` / `TORCH_CHECK` API.
- **File placement / hipify:** upstream hand-writes
`io/image/hip/decode_jpegs_cuda.cpp`. On `release/0.26` the ROCm build
hipifies `io/image/cuda/*` into `hip/`, so the rocJPEG path lives in
`cuda/decode_jpegs_cuda.{cpp,h}` guarded by `#if ROCJPEG_FOUND` and
flows through hipify (verified: it transforms cleanly into
`hip/decode_jpegs_hip.cpp` with the `decode_jpegs_cuda` symbol and all
`rocJpeg*` calls intact).
- **Op registration:** `release/0.26` registers via a single
`.op("image::decode_jpegs_cuda", ...)` in `image.cpp`, so the upstream
dual `#if !ROCJPEG_FOUND` registration split was not needed.
- **setup.py:** added `USE_ROCJPEG` + `ROCJPEG_FOUND` detection to
`make_image_extension` (no `STABLE_SOURCES` / `image_stable` plumbing,
which don't exist here).

## Changes

- `torchvision/csrc/io/image/cuda/decode_jpegs_cuda.h` -
`RocJpegDecoder` class + `CHECK_ROCJPEG`/`CHECK_HIP` macros under `#if
ROCJPEG_FOUND`.
- `torchvision/csrc/io/image/cuda/decode_jpegs_cuda.cpp` - rocJPEG
decode implementation (classic API); stub guard changed to `#if
!NVJPEG_FOUND && !ROCJPEG_FOUND`.
- `setup.py` - `TORCHVISION_USE_ROCJPEG` / `ROCJPEG_FOUND` detection and
`rocjpeg` linkage.
- `test/test_image.py` - `IS_ROCM` tolerance bump for decode; skip GPU
JPEG *encoder* tests (rocJPEG is decode-only).
- `torchvision/io/image.py` - docstring note about the rocJPEG path.

## Capability notes

rocJPEG uses `ROCJPEG_BACKEND_HARDWARE`, which rejects images smaller
than 64x64 and 4:1:1 / unknown chroma subsampling.

## Validation

Built via TheRock "Multi-Arch Build Portable Linux PyTorch Wheels"
against this pin:
https://github.com/ROCm/TheRock/actions/runs/28960912700
- Build (torch + rocJPEG torchvision, gfx94X, py3.12): **success**.
- PyTorch test suite: 39627 passed; the only 4 failures are unrelated
(`test_unary_ufuncs.py` uint8 `threshold` OverflowError), not
JPEG/torchvision.

## Companion PR

Pin bump in ROCm/pytorch `release/2.11`: ROCm/pytorch#3411